PATENT - AMENDMENT 



Remarks/Arguments 

L Status of the Claims 

In the non-final Office action, the Examiner indicates that claims 1-17 are 
pending, rejects claims 1-4, 6-14, and 16-17 under 35 U.S.C. 102(e), and rejects claims 5 
and 15 under 35 U.S.C. 103(a). 

Claims 1, 4, 1 1 and 14 are amended in this Amendment to correct typographical 
errors. In addition, the specification is amended at pages 6, 17 and 24 to correct similar 
typographical errors. 

New independent claim 18 is introduced by this Amendment. Consequently, 
claims 1-18 are pending for reconsideration. 

IL Information Disclosure Statement 

At page 2, item 2 of the non-final Office action, the Examiner indicates that the 
listing of references in the specification is not a proper information disclosure statement. 

In order to assure that the references listed in the specification are considered by 
the Examiner, the Applicants file herewith a proper Information Disclosure Statement, 
which is submitted under 37 CFR 1.97(c) and is accompanied by the requisite fee under 
37CFR1.17(p). 

The Examiner is respectfully requested to consider each of the references listed in 
the Information Disclosure Statement. 
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UL Rejection of claims 1-4, 6-14. and 16-17 under 35 U.S.C. §102(^1 

At pages 2-5, item 4 of the non-final Office action, claims 1-4, 6-14, and 16-17 
are rejected under 35 U.S.C. § 102(e) as being anticipated by Klemets et al. (U.S. Patent 
Application Publication No. US 2003/0236912 Al). 

This rejection is respectfully traversed to the extent that it is maintained. A proper 
rejection under 35 U.S.C. §102 requires that the reference disclose each and every 
element of the invention as claimed. However, as discussed below, the Klemets et al. 
reference fails to disclose (or even suggest) the claimed invention. 

Independent claims 1, 8 and 1 1 each require that a request for a particular media 
file is received from a client computer or web client, and a metafile or metadata is 
returned. 

In the method for streaming a media file over a distributed information system as 
recited in independent claim 1, a download request for the actual media file is 
reinterpreted into a request for receiving a corresponding metafile, which is returned back 
to the client computer. The metafile contains information about the identification, 
location and format of the media file. 

In the device for streaming a media file over a network as recited in independent 
claim 8, metadata for initiating the streaming of a media file is returned to a web client in 
response to a request for the media file. 

In the computer-readable program stored on a computer-readable medium as 
recited in independent claim 1 1, a download request for the actual media file is 
reinterpreted into a request for receiving a corresponding metafile, which is returned back 
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to the client computer. The metafile contains information about the identification, 
location and format of the media file. 

In the case of each of independent claims 1 , 8 and 1 1 , a request for a media file is 
received but instead of returning the content of the resource requested (default HTTP 
behavior) or executing the resource and forwarding it's reply (Java Servlets, CGI scripts) 
- a metafile or metadata is returned. 

At this point, reference to specification of the present application and the preferred 
embodiments described therein may be instructive. In accordance with the preferred 
embodiments of the present invention, a HTTP request composed by a web browser 122 
running on a web client 102 points to a media file itself, and neither to a streaming 
metafile nor a CGI/Java Servlet program component. See, for example, page 11, lines 
14-19 of the present application. The HTTP request is forwarded to a metadata server 
104, which forwards the request to a HTTP protocol handler 132. See, for example, page 
11, lines 20-25 of the present application. Usually, a HTTP protocol handler would 
answer an HTTP request either by returning the content of the resource requested (default 
HTTP behavior) or executing the resource and forwarding it's reply (Java Servlets, CGI 
scripts). However, the HTTP protocol handler 132 according to the preferred 
embodiments of the present invention, reinterprets the HTTP request so that it returns 
streaming metadata instead. See, for example, page 12, lines 1-5 of the present 
application. For all HTTP requests fulfilling predefined filter criteria, the metadata server 
returns metadata instead of the original media content. See, for example, page 7, lines 8- 
14 of the present application. (Incidently, this latter feature directly relates to the subject 
matter of dependent claims 5 and 15, each of which positively recites the step of 
"checking predefined filter criteria determining of whether or not a metafile is to be 
returned instead of the requested media file.") 
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At page 3, lines 1-4 of the non-final Office action, the Examiner states, "With 
regards to claim 1, Klemets discloses ... receiving a request for a particular media file 
from a client computer (Klemets: Paragraph [0016]); ... " Also, at page 3, lines 1-12 of 
the non-final Office action, the Examiner states, "With regards to claim 1, Klemets 
discloses ... returning said metafile back to said client computer (Klemets: Paragraph 
[0039]), Contrary to the assertion of the Examiner, however, the Klemets et al. 
reference does not disclose (or even suggest) "receiving a request for a particular media 
file from a client computer" and "returning said metafile back to said client computer". 
(As defined in claim 1, the metafile returned to the client computer contains information 
about the identification, location and format of the media file.) The Klemets et al 
reference does not disclose (or even suggest) returning a metafile that contains 
information about the identification, location and format of a particular media file in 
response to receiving a request for that particular media file as required by independent 
claim 1 . 

Instead, the Klemets et al. reference discloses the client 106 initially sends a real- 
time streaming protocol (RTSP) DESCRIBE request to the media server 104. Then, the 
media server 104 responds to the RTSP DESCRIBE request with a session description 
protocol (SDP) message. The SDP message includes a streaming media format file 
header and the content description list. See, Klemets et al., page 3, paragraph [003 1]. In 
other words, the client 106 sends a description request (e.g., an RTSP DESCRIBE 
request) to the server 104 to describe the available content. See, Klemets et al., page 4, 
paragraph [0041]. This first communication session (i.e., sending the RTSP DESCRIBE 
request and returning the SDP message) between the client and the media server as 
disclosed in the Klemets et al. reference does not correspond to the claimed steps of 
sending a request for a particular file and returning a metafile that contains information 
about the identification, location and format of that particular media file. Granted, the 
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SDP message may arguably contain metadata, but the RTSP DESCRIBE request is 
clearly not a request for a particular media file as independent claim 1 requires. 

The Klemets et al. reference further discloses the client 106 next sends a playback 
request (e.g., an RTSP SETUP request) for each stream that the client 106 has chosen. 
The client 106 may also send a RTSP PLAY request for each stream that has been chosen 
to initiate delivery of the chosen streams. Finally, in response to the playback request, the 
media server 104 sends the selected streams (e.g., via real-time transport protocol (RTP)) 
to the client 106. See, Klemets et al., pages 4-5, paragraph [0045]. This second 
communication session (i.e., sending the RTSP SETUP/PLAY request and returning the 
selected streams) between the client and the media server as disclosed in the Klemets et 
al. reference, also does not correspond to the claimed steps of sending a request for a 
particular file and returning a metafile that contains information about the identification, 
location and format of that particular media file. Granted, the RTSP SETUP/PLAY 
request may arguably be construed as a request for a particular media file, but the selected 
streams are clearly not a metafile that contains information about the identification, 
location and format of that particular media file as independent claim 1 requires. 

Thus, neither the first communication session nor the second communication 
session between the client and the media server as disclosed in the Klemets et al. 
reference corresponds to sequence of steps required by independent claim 1, i.e., 
receiving a request for a particular media file and then returning a metafile that contains 
information about the identification, location and format of that particular media file. 
The Klemets et al. reference is similarly deficient with respect to the corresponding 
limitations of independent claims 8 and 1 1 . 
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Likewise, claims 2-4, 6-7, 9-10, 12-14, and 16-17 depend, directly or indirectly, 
from independent claim 1, 8 or 1 1, and set forth all of the limitations therein, plus 
additional limitations that are not disclosed (or even suggested) by the prior art. By such 
additional limitations, and for at least the reasons discussed above with respect to 
independent claims 1, 8 and 1 1, the Applicants respectfully submit that these dependent 
claims also patentably define over the prior art. 

Therefore, the Applicants respectfully request reconsideration and withdrawal of 
this rejection of claims 1-4, 6-14, and 16-17 under 35 U.S.C. §102(e). 

IV, Rejection of claims 5 and 15 under 35 U.S.C. S 103(a) 

At pages 5-7, item 6 of the non-final Office action, claims 5 and 15 are rejected 
under 35 U.S.C. § 103(a) as being unpatentable over Klemets et al. (U.S. Patent 
Application Publication No. US 2003/0236912 Al) over "knowledge possessed by a 
person of ordinary skill in the art". 

This rejection is respectfully traversed to the extent that it is repeated. As 
discussed below, the cited art fails to disclose or suggest the claimed invention. 

Claims 5 and 15 depend, directly, from independent claim 1 and 1 1 , respectively, 
and set forth all of the limitations therein. Accordingly, for at least the reasons discussed 
above with respect to independent claims 1 and 1 1, the Applicants respectfully submit 
that dependent claims 5 and 15 also patentably define over the prior art. The Examiner 
alleges (without objective evidence of a basis in fact for this allegation) the knowledge 
possessed by a person of ordinary skill in the art cures the deficiencies of the Klemets et 
al. reference with respect to the "checking predefined filter criteria determining of 



Docket No.: GE920020019US1 
Serial No.: 10/624,353 



14 



PATENT - AMENDMENT 



whether or not a metafile is to be returned instead of the requested media file" limitation 

of dependent claims 5 and 15. The Applicants do not agree ~ the Examiner has 

not shown, for example, that the variation he suggests is within the skill level of 

a person of ordinary skill in the art, is a predictable variation, or has been used 

to improve similar devices in the same way. Irrespective, the knowledge possessed by a 

person of ordinary skill in the art fails to cure the above-discussed deficiencies of the 

Klemets et al. reference with respect to independent claims 1 and 11. 

Therefore, the Applicants respectfully request reconsideration and withdrawal of 
this rejection of claims 5 and 15 under 35 U.S.C. §103(a). 

V. New Independent Claim 18 

New independent claim 18 is introduced in this Amendment to provide an 
additional scope of claim protection for the present invention. This claim is directed to a 
method for streaming a media file over a distributed information system to a client 
computer by sequentially interacting with two different servers ~ the first being a 
metadata server and the second being a streaming server. No new matter has been added. 
See, for example, the discussion of the web client 102, the metadata server 104 and the 
delivery server 106 at pages 10-14 of the present application, with reference to FIG. 1. 

Hence, the method for streaming a media file as recited in new independent claim 
18 requires the use of two distinct servers, i.e., the metadata server and the streamer 
server. This arrangement is advantageous in several respects. For example, one metadata 
server may cooperate with multiple delivery servers in order to perform load balancing. 
The prior art simply fails to disclose or suggest a method for streaming a media file as 
recited in new independent claim 18, and the advantages the flow therefrom. 
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VL Conclusion 

In view of the foregoing comments and amendments, the Applicants respectfully 
submit that all of the pending claims (i.e., claims 1-18) are in condition for allowance and 
that the application should be passed to issue. 

If a conference would be of value in expediting the prosecution of this 
application, the Examiner is hereby encouraged to telephone the undersigned counsel at 
(847) 462-1937 to arrange for such a conference. 



Respectfully submitted, 




Telephone: (847)462-1937 
Fax No.: (847)462-1937 



1048 Dove Way 
Cary, Illinois 60013 
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